Mobile payment system and method

ABSTRACT

A merchant web site automatically detects whether a customer device has a registered payment application; if so, the web site generates a custom protocol message that is triggered on checkout to initiate payment via the payment application. Details of the transaction are passed to the payment application via a payment server so that the user can authorise the transaction within the payment application.

FIELD OF THE INVENTION

This invention relates to a system and method for online payment using apayment application.

BACKGROUND OF THE INVENTION

Conventional methods of online payment include an online checkout model,where a customer orders a ‘basket’ of goods or services on a merchantwebsite, and selects a ‘checkout’ option to order and pay for thecontents of the basket. Payment may be effected by entering details of apayment card, including card number, card holder name, card expiry data,CVC code and billing address. Some of these details may be pre-stored tosave the customer from entering them every time, but this raisessecurity issues.

In an alternative ‘hosted checkout’ model, payment is handled by a thirdparty payment service such as PayPal® or Google Checkout®. A checkoutpage of the merchant website includes one or more ‘pay buttons’ whichlaunch the payment service; the customer logs on to the payment service,and if the payment is authorised, a confirmation is sent to the merchantto complete the transaction.

SUMMARY OF THE INVENTION

Different aspects of the present invention are defined in claims 1, 18,19 and 20.

In an embodiment of the invention, an online merchant automaticallydetects whether a customer device has a registered payment application;if so, the web site generates a custom protocol message that istriggered on checkout to initiate payment via the payment application.Details of the transaction are passed to the payment application so thatthe user can authorise the transaction within the payment application.In order to securely pass these details to the payment application, themerchant passes a payment request token and transaction details to apayment server that processes payments for the payment application. Thepayment request token is also passed in the custom protocol message tothe payment application, which uses the payment request token to obtainthe transaction details from the payment server. The transaction detailsare then presented to the user when requesting authorisation of thetransaction by the payment application. In this way, the transactiondetails can be passed securely to the payment application. Tamperingwith the payment amount and transaction details, for example via ‘Man inthe Middle’ or malicious users can thereby be avoided.

After the user authorises the transaction, the payment applicationindicates the outcome of the authorisation request to the paymentserver, which returns a corresponding outcome token to the paymentapplication; the outcome token is passed to the merchant server by thepayment application so that the authorisation outcome is securelycommunicated to the merchant, who may then process the transaction basedon the outcome.

The online merchant may apply time restrictions to authorisation of atransaction; for example, a basket may time out if a time period isexceeded, in order to conserve resources. If the time restrictions areexceeded, then the transaction details may be recovered from the paymentserver and used to restore the transaction with the online merchant. Theonline merchant may amend the transaction details, for example bychecking price or availability, before processing the transaction.

There may be provided a device, a merchant server, a payment server andassociated computer programs arranged to carry out the above method.

BRIEF DESCRIPTION OF THE DRAWINGS

There now follows, by way of example only, a detailed description ofembodiments of the present invention, with reference to the figuresidentified below.

FIG. 1 is a diagram of the main components of a mobile payment systemaccording to embodiments of the invention.

FIG. 2 is a flow diagram illustrating method steps in an embodiment ofthe invention.

FIG. 3 is a diagram of a mobile device for use in embodiments of theinvention.

FIG. 4 is a diagram showing details of a computer system for use inembodiments of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION TechnicalArchitecture

Referring to FIG. 1, a mobile payment system according to embodiments ofthe invention comprises a wireless or mobile communication device 1having a payment application 1 a, connected or connectable to a paymentserver 4 over a network 3. The payment server 4 interacts with thepayment application 1 a to authorise and process payments by interactionwith an authenticated user of the payment application 1 a. The paymentserver 4 has access to one or more database(s) 7 including registrationdata relating to the payment application 1 a and transaction datarelating to specific payment sessions.

The payment server 4 may be connected to, or may comprise a paymentfulfilment service of a type that is known per se. The paymentfulfilment service executes requested payments between specifiedaccounts.

The device 1 may also have a mobile browser application 1 b, or adedicated application, for accessing and interacting with an onlinestore hosted by a merchant server 8 connected to the network 3. Theonline store displays items that a customer may select for purchase, andstores the selected item(s) selected by the customer during a session ina ‘basket’ or other model representing a set of items selected forpurchase. The merchant server 8 may comprise multiple components, suchas a web server for serving web pages to a customer's browser and aback-end server for storing data representing customers and baskets, andinterfacing with payment systems. The device 1 may be a client of themerchant server 8, although embodiments of the invention may not belimited to a client-server model.

The device 1 may be of a type that is known per se, such as an iOS™,Blackberry™ or Android™ based smartphone, a ‘feature’ phone, a personaldigital assistant (PDA), a tablet computer, or any processor-powereddevice with suitable input and display means. In some embodiments, thedevice 1 need not have a voice telephony function. The device 1 may be aterminal of the network 3.

The network 3 may comprise a terrestrial cellular network such as a 2G,3G or 4G network, a private or public wireless network such as aWiFi™-based network and/or a mobile satellite network or the Internet.It will be appreciated that a plurality of, and preferably a largenumber of devices 1 and merchant servers 8 are operable concurrentlywithin the system.

Introduction

An online payment process in an embodiment of the present invention willnow be described with reference to the steps S1 to S12 shown in FIG. 2.Step S1 comprises an initial setup and registration process, while stepsS2 to S12 comprise a specific payment session, and may be repeated insubsequent payment sessions.

Registration

S1—the user installs the payment application 1 a on the device 1. Aspart of this process, the application 1 a is associated with a customprotocol handler; this may take the form of a URL (Uniform ResourceLocator) beginning ‘bpay://’, for example. The payment application 1 ais also registered with the payment server 4, by providing verifiedaccount information and by setting up a secure communications protocolbetween the application 1 a and the payment server 4, for example bysetting up one or more cryptographic keys associated with a passcodeassociated with a registered user. The key(s) may be generated from thepasscode as entered by the user during setup. The passcode may be a PIN,graphical passcode and/or biometric data such as a fingerprint or irisscan. The passcode may be modified by the user after setup.

In the specific embodiments described below, a user is required to enterthe passcode as part of an authentication process. The passcode may beentered as a numeric or alphanumeric input, a graphical input such as asignature or gesture, or a biometric input. Preferably, the passcode isvalidated remotely, for example by generating a cryptographic key fromthe passcode, which key is used to sign a message sent to the paymentserver 4 and/or a challenge sent by the payment server 4. The paymentserver 4 may only respond as described in the embodiments below if theresulting signature is validated. If not, the payment server 4 mayprompt the application 1 a to request the passcode again. The paymentserver 4 may block access by the application 1 a if it presents aninvalid signature more than a predetermined number of times. In thisway, the authentication process is made resistant to ‘brute force’attacks.

Alternatively the entered passcode may be validated locally against apasscode stored in a local secure area of the device 1. If the passcodeis validated, then the mobile application 1 a is enabled to operate, forexample as described in the specific embodiments below. This enablementmay include access to locally stored cryptographic key(s) for securecommunication with the payment server 4.

Payment process

S2—the user browses an online store, for example on a website using themobile browser 1 b or other application. The user selects one or moreitems which are added to a ‘basket’ or any other model representing aset of items selected for purchase. The user, wishing to complete thepurchase, then selects a ‘checkout’ option on the website.

S3—The merchant server 8 detects that the user is accessing the onlinestore using a device having the payment application 1 a registeredthereon. Preferably, this detection is performed automatically, withoutthe need for user intervention such as the user interacting with thepayment application 1 a on the mobile device 1. Detection may be donewhen the reaching the checkout stage, or at an earlier stage of thesession. The detection may be performed by any of the following methods:

-   -   The mobile browser 1 b is integrated with the payment        application 1 a, for example by wrapping, monitoring or via a        plug-in, so that the payment application 1 a passes identifying        information to the merchant server 8 during the ordering        process, for example by injecting HTTP headers, data fields or        cookies into the browser.    -   The merchant server 8 runs a ‘beacon’ script or request (e.g.        bpay://beaconRequest) that attempts to access the payment        application 1 a in the background; if the payment application 1        a responds to the beacon request, the merchant server 8 detects        that the payment application 1 a is present.    -   The merchant server 8 sets up a call back for the payment        application 1 a.    -   The merchant server 8 may trigger a standardised request to the        mobile device 1 to use a cloud service or commonly installed        application (e.g. Facebook™) to return an attribute that        indicates the user has the payment application 1 a installed.        The standardised request and attribute return is authorised by        the user e.g. via an secure authorisation protocol such as        OAuth.

Alternatively, the user may select an option presented by the onlinestore to pay via the payment application 1 a.

If the payment application 1 a is detected, then the merchant server 8generates a payment request token identifying the merchant and thebasket, and including a return address, for example a URL to a merchantservice.

S4—the merchant server 8 makes the payment request token available tothe payment server 4, either by a ‘push’ model in which the token issent to the payment server 4, or a ‘pull’ model in which the paymentserver 4 reads the token from the merchant server 8. The merchant server8 also makes transaction data available to the payment server, includingfor example the total amount to be paid, information on specific itemswithin the basket such as name and individual cost, and/or any specificconditions associated with the purchase. Alternatively, the transactiondata may be included within the payment request token, in which case thetransaction data should be protected from tampering by suitablecryptographic means, for example by encryption, a digital signature or ahash-based authentication code (HMAC).

S5—the merchant server 8 creates a custom protocol message to pass thepayment request token to the payment application 1 a identified in stepS3. For example, a custom URL or URI (Uniform Resource Identifier) maybe created beginning with the custom protocol handler and including thepayment request token (e.g. bPay://PaymentToken). The merchant server 8presents to the device 1, at the checkout stage, an option to pay usingthe payment application 1 a, for example by displaying a pay button thattriggers the custom URL.

S6—the user wishing to pay using the mobile application 1 a selects thatoption from the merchant web site, for example by clicking the paybutton.

S7—In response to the selection at step S6, the device 1 receives thecustom protocol message, including the payment request token. The device1 identifies the payment application 1 a as being associated with thecustom protocol handler and therefore passes the custom protocol messageto the payment application 1 a. The payment application 1 a may belaunched automatically by the device 1, if not already open. The usermay be authenticated by the payment application 1 a, for example byentering a passcode as described above, if this has not already beendone.

S8—the payment application 1 a retrieves the transaction data for therelevant session from the payment server 4, using the payment requesttoken as a reference. The payment server 4 may already have received thetransaction data at step S4, or may obtain the transaction data from themerchant server 8 at this point, for example using a merchant identifierwithin the payment request token, together with relevant configurationinformation to allow the payment server 4 to contact the correctmerchant server 8.

S9—The payment application 1 a displays or otherwise communicates atleast some of the transaction data to the user and requests the user toauthorise the purchase of the items in the basket. The user may simplychoose between ‘accept’ or ‘decline’ options, or may additionally selecta mode of payment, such as payment from a specific bank accountregistered with the payment application 1 a, and/or a wallet accountassociated with the payment application 1 a.

S10—the payment application 1 a informs the payment server 4 of theoutcome of the purchase authorisation request. If the request isauthorised, the payment server 4 may initiate payment from thedesignated user account to the merchant.

S11—in response to the outcome information, the payment server 4 issuesa payment outcome token to the payment application 1 a. The paymentoutcome token may for example contain a unique transaction reference andintegrity code, or may simply be a random or one-time code thatreferences transaction information accessible on the payment server 4.

S12—the payment application 1 a passes the payment outcome token to themerchant server 8, for example by generating and launching aconfirmation URL to the merchant server 8, including the return addressand the payment confirmation token. The merchant server 8 may obtaintransaction details from the payment server 4 using the paymentconfirmation token, which may be a SAML token, a custom token withsuitable cryptographic controls, or a large random number similar to theSAML artefact model. Where a SAML or other signed token is used, themerchant server 8 does not need to contact the payment server 4 once thetoken is validated.

S13—the merchant server 8 processes the transaction in accordance withthe outcome indicated by the payment outcome token: if the purchase isauthorised, the transaction may be completed by processing the order forthe items in the basket; if the purchase is declined, the transaction iscancelled. Alternatively, the merchant server 8 may query the paymentserver 4 with the original payment request token to find out theoutcome, for example if the payment outcome token does not arrive at themerchant server 8.

As an optional additional step, the merchant server 8 may be required topresent the payment outcome token to the payment server 4 in order toconfirm that the transaction has been completed, and payment to themerchant may be suspended until this additional step is completed.

In an alternative embodiment, after the payment server 4 has receivedthe transaction data from the merchant server 8 at step S4, the paymentserver 4 may interact directly with the payment application 1 a, forexample via a push message, to obtain authorisation for the transaction.The payment server 4 then sends the payment outcome token to themerchant server 8, which processes the transaction in accordance withthe indicated outcome.

Basket Recovery Process

The above description assumes that the payment process is notinterrupted. However, in the event of a break-down or potential failurein one or more of the steps, one or more additional recovery processesmay be invoked, examples of which are described below.

The online store hosted by the merchant server 8 may require checkout tobe completed within a specified period of time or by a specified cut-offtime, for example to conserve resources or to release reserved items forpurchase by other customers. If a time-out condition occurs between stepS6 and step S12, the recovery process may be one of the following:

-   -   The transaction data obtained by the payment server 4 at step        S4, or subsequently, may be returned to the merchant server 8 so        that the transaction can be restored.    -   The merchant server 8 checks current availability and/or price        of the items in the basket and may modify the transaction data        if availability or price have changed.    -   If one or more of the items in the basket are no longer        available, the merchant server 8 may amend the basket, for        example by removing the unavailable item(s), offering        alternatives to the unavailable item(s) or applying a reduced        price; payment for the amended basket may then be processed, for        example by repeating steps S7 to S13.    -   The merchant server 8 may process the transaction and issue a        refund for any unavailable items, for example by further        communication with the payment server 4 and/or the payment        application 1 a.    -   The merchant server 8 may cancel the transaction.

Alternative Embodiments and Applications

The above embodiments are described by way of example, and alternativeembodiments which may become apparent to the skilled person on readingthe above description may nevertheless fall within the scope of theclaims.

Device Details

FIG. 3 shows further details of one example of the device 1 comprisingat least a processor 10, including for example hardware and anapplication platform, running the payment application 1 a, and connectedto memory or other form of data storage facility such as flash drive 13storing local data 14. The application platform may be a mobileoperating system such as iOS™, Android™, Blackberry OS, Windows-basedOS, or other embedded OS such as Open Embedded Build system, Symbian OS,Contiki, FreeBSD, and TinyOS. The application 1 a may comprise programcode, which can be loaded or downloaded onto the device 1.

The device 1 has a display 11 and a manual input device 12, which may beintegrated with the display as a touchscreen, and/or provided as akeypad. An alternative or additional input device may be used, such as atrackball, trackpad, motion sensor or mouse.

The device 1 includes a network interface 15 to the network 3.

Computer Details

The merchant server 4 and/or the payment server 7 may be implemented bycomputer systems such as computer system 1000 as shown in FIG. 4.Embodiments of the present invention may be implemented as programmablecode for execution by such computer systems 1000. After reading thisdescription, it will become apparent to a person skilled in the art howto implement the invention using other computer systems and/or computerarchitectures.

Computer system 1000 includes one or more processors, such as processor1004. Processor 1004 may be any type of processor, including but notlimited to a special purpose or a general-purpose digital signalprocessor. Processor 1004 is connected to a communication infrastructure1006 (for example, a bus or network). Various software implementationsare described in terms of this exemplary computer system. After readingthis description, it will become apparent to a person skilled in the arthow to implement the invention using other computer systems and/orcomputer architectures.

Computer system 1000 also includes a main memory 1008, preferably randomaccess memory (RAM), and may also include a secondary memory 610.Secondary memory 1010 may include, for example, a hard disk drive 1012and/or a removable storage drive 1014, representing a floppy disk drive,a magnetic tape drive, an optical disk drive, etc. Removable storagedrive 1014 reads from and/or writes to a removable storage unit 1018 ina well-known manner. Removable storage unit 1018 represents a floppydisk, magnetic tape, optical disk, etc., which is read by and written toby removable storage drive 1014. As will be appreciated, removablestorage unit 618 includes a computer usable storage medium having storedtherein computer software and/or data.

In alternative implementations, secondary memory 1010 may include othersimilar means for allowing computer programs or other instructions to beloaded into computer system 1000. Such means may include, for example, aremovable storage unit 1022 and an interface 1020. Examples of suchmeans may include a removable memory chip (such as an EPROM, or PROM, orflash memory) and associated socket, and other removable storage units1022 and interfaces 1020 which allow software and data to be transferredfrom removable storage unit 1022 to computer system 1000. Alternatively,the program may be executed and/or the data accessed from the removablestorage unit 1022, using the processor 1004 of the computer system 1000.

Computer system 1000 may also include a communication interface 1024.Communication interface 1024 allows software and data to be transferredbetween computer system 1000 and external devices. Examples ofcommunication interface 1024 may include a modem, a network interface(such as an Ethernet card), a communication port, a Personal ComputerMemory Card International Association (PCMCIA) slot and card, etc.Software and data transferred via communication interface 1024 are inthe form of signals 1028, which may be electronic, electromagnetic,optical, or other signals capable of being received by communicationinterface 1024. These signals 1028 are provided to communicationinterface 1024 via a communication path 1026. Communication path 1026carries signals 1028 and may be implemented using wire or cable, fibreoptics, a phone line, a wireless link, a cellular phone link, a radiofrequency link, or any other suitable communication channel. Forinstance, communication path 1026 may be implemented using a combinationof channels.

The terms “computer program medium” and “computer usable medium” areused generally to refer to media such as removable storage drive 1014, ahard disk installed in hard disk drive 1012, and signals 1028. Thesecomputer program products are means for providing software to computersystem 1000. However, these terms may also include signals (such aselectrical, optical or electromagnetic signals) that embody the computerprogram disclosed herein.

Computer programs (also called computer control logic) are stored inmain memory 1008 and/or secondary memory 1010. Computer programs mayalso be received via communication interface 1024. Such computerprograms, when executed, enable computer system 1000 to implementembodiments of the present invention as discussed herein. Accordingly,such computer programs represent controllers of computer system 1000.Where the embodiment is implemented using software, the software may bestored in a computer program product and loaded into computer system1000 using removable storage drive 1014, hard disk drive 1012, orcommunication interface 1024, to provide some examples.

Alternative embodiments may be implemented as control logic in hardware,firmware, or software or any combination thereof.

1. A computer implemented method of providing candidate informationassociated with an ID candidate from a verification service to an IDchecker, the ID candidate having a first communication device and the IDchecker having a second communication device, the method comprising: a)obtaining a challenge code from the verification service at one of thefirst and second devices; b) passing the challenge code from the firstdevice to the other of the first and second devices; c) verifying thepassed challenge code with the verification service and, if thechallenge code is verified, d) providing the candidate information fromthe verification service to one of the first and second devices, suchthat the candidate information is accessible to the ID checker under thecontrol of the ID candidate.
 2. The method of claim 1, wherein thechallenge code does not contain identity information pertaining to theID candidate.
 3. The method of claim 1, wherein the candidateinformation is provided to the first device, for output to the IDchecker.
 4. The method of claim 1, wherein the candidate information isprovided to the second device.
 5. The method of claim 4, wherein thestep of providing candidate information comprises sending an approvalrequest to the first device, and if approval is confirmed on the firstdevice, sending the candidate information to the second device.
 6. Themethod of claim 5, wherein the candidate information comprises aplurality of items, one or more of the items is selected for approval onthe first device, and the selected one or more items are sent to thesecond device.
 7. The method of claim 1, including specifying, on thesecond device, the candidate information required.
 8. The method ofclaim 7, wherein the required candidate information includes aconfirmation that a specified criterion is met.
 9. The method of claim7, wherein the approval request indicates the candidate informationrequired.
 10. The method of claim 1, including, if the challenge code isverified, sending an acknowledgement message to at least one of thefirst and second devices.
 11. The method of claim 10, wherein theacknowledgement message includes the candidate information provided. 12.The method of claim 1, including, if the challenge code is verified,providing a validation code to the first and second devices.
 13. Themethod of claim 12, wherein the validation code comprises a one-timecode.
 14. The method of claim 12, wherein the validation code israndomly or pseudo-randomly selected from a predefined set of codes. 15.The method of claim 12, wherein the validation code comprises agraphical image.
 16. The method of claim 12, wherein the validation codeis provided in response to a request from one or bath of the first andsecond devices.
 17. The method of claim 16, wherein a further validationcode is provided in response to a request from one or bath of the firstand second devices.
 18. The method of claim 12, wherein the validationcode is output by both the first and second devices.
 19. The method ofclaim 1, wherein the ID candidate is authenticated with the firstdevice.
 20. The method of claim 1, wherein the ID checker isauthenticated with the second device.
 21. The method of claim 1, whereinthe first device is a mobile communication device.
 22. The method ofclaim 1, wherein the second device is a mobile communication device. 23.The method of claim 1 wherein the challenge code is displayed as a codeand is passed by scanning.
 24. The method of claim 23, wherein thechallenge code is displayed as a machine-readable code.
 25. The methodof claim 24, wherein the challenge code is displayed as atwo-dimensional code.
 26. A non-transitory computer readable storagemedium storing a computer program including program code means arrangedto perform the method of claim 1, when executed by a suitably arrangedprocessor or processors.
 27. A computer program product comprising thenon-transitory computer readable storage medium of claim
 26. 28.Apparatus arranged to perform the method of claim
 1. 29. A system forproviding candidate information, the system comprising: a) a firstdevice associated with an ID candidate, b) a second device associatedwith an ID checker, c) a verification service, and d) a database,wherein one of the first and second devices is arranged to obtain achallenge code from the verification service; wherein the other of thefirst and second devices is arranged to capture the challenge code andto verify the challenge code with the verification service; and whereinthe verification service is arranged to provide the candidateinformation from the data base in response to verification of thechallenge code, such that the candidate information is accessible to theID checker under the control of the ID candidate.
 30. A non-transitorycomputer readable storage medium storing an ID checker applicationcomprising program code arranged to perform the following steps: a)capture a challenge code from a device associated with an ID candidate;and b) verify the challenge code with a verification service; such thatcandidate information associated with the ID candidate is provided. 31.A non-transitory computer readable storage medium storing an IDcandidate application comprising program code arranged to perform thefollowing steps: a) request a challenge code from a verificationservice; and b) output the challenge code to a device associated with anID checker; such that candidate information associated with the IDcandidate is provided.